Hacker News new | past | comments | ask | show | jobs | submit login

I'm going to disagree with you. The problem with PHP is that there's no easy way of sharing state between requests.

If you have a separate (ini-style) configuration file, every time you get a new request, the file will have to be read in from disk and parsed. On heavily-loaded web servers this can be a significant performance issue.

Configuration stored in a PHP file will be cached by your opcode cache and so doesn't incur any per-request parsing/reading overhead.

The problem here is not that Tumblr stored their configuration in PHP. The problem is their lack of testing their changes.

(As I mentioned elsewhere in the thread, this particular nasty issue can be solved by simply enforcing that every .php file begins in '<?'.)




> If you have a separate (ini-style) configuration file, every time you get a new request...

it will just pull it from the cache, not needing to be parsed or read from disk.

Configuration stored in a PHP file is bad. Changing working code simply because you want to add a new slave is a horrible idea. It would be like having to recompile Apache from source every time you want to add a new vhost because all the entries are written in C.

Interpreted languages like PHP, Python, Perl, etc all make it easy to put config options directly into the language. When your app is small, it's fine. But as it gets larger, move it out.

But yes, that they didn't even catch this is in testing is the real problem.


> it will just pull it from the cache, not needing to be parsed or read from disk.

I don't believe PHP's ini_read caches anything. Sure, your OS cache is going to have that file in, but PHP still has to do the fopen(), fread(), parse, fclose() dance on every page hit. This does not happen with an opcode-cached source file.

I have actually benchmarked this. Amortized across billions of page hits per month it produces a notable saving.

Kudos points out that you could use APC - this is absolutely true but IMO it basically equates to doing the same thing in a more complex way.

> Configuration stored in a PHP file is bad. Changing working code simply because you want to add a new slave is a horrible idea. It would be like having to recompile Apache from source every time you want to add a new vhost because all the entries are written in C.

This is a false comparison between interpreted and compiled languages. Not to mention that plenty of C programs use #defines for configuration. Varnish even translates its configuration language into C and dynamically loads it as a module, which provides significant flexibility.

In a dynamic language, and where you trust the person doing the configuration, there's no reason why your configuration shouldn't be in a source file. Both Django and Rails do it this way.


"In a dynamic language, and where you trust the person doing the configuration, there's no reason why your configuration shouldn't be in a source file. Both Django and Rails do it this way."

Not true. In Rails, sensitive information like database passwords or AWS keys are not stored in the source, you store them in configuration files, YAML files by default. It's also widely recommended that these not be checked into version control.


My bad - it's been a while since I touched Rails and my memory was rusty.


> I don't believe PHP's ini_read caches anything.

I wasn't referring to straight PHP. There are multiple ways to cache the config file's contents so you don't have to hit the disk to read.

> This is a false comparison between interpreted and compiled languages. Not to mention that plenty of C programs use #defines for configuration.

Your misunderstanding me here. I'm not saying #defines are bad. However, they are a different level of configuration from vhosts. You aren't #defining your virtual hosts. Same with php. You have the C code with specific options being set, and then php.ini for the user facing stuff.

> In a dynamic language, and where you trust the person doing the configuration, there's no reason why your configuration shouldn't be in a source file.

Except we saw at least one reason today.


> I don't believe PHP's ini_read caches anything.

so check if the ini file key is in memcache, if so get it from there, if not, ini_read it and populate the cache. Not hard.


Sure there is, APC. But that aside, Linux won't read that file every time, it will end up living in the disk buffers that it maintains.


The disk buffers make the operation cheap but not free, i.e. keeping the information cached is the right thing to do.


If that is a big problem, pass secrets as environment variables. These are getting passed and read anyway.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: