Looking at creating my first web application using php and an opcode cache.
I vaguely understand why it's beneficial in theory.
However, in practice - how does apc work with opcodes compiled from session specific variables? If one page (say somesharedpage.php) is cached, how are variables within (that may be different for every user) treated and handled?
Simply, APC works with code and not data, because data doesn't contain any opcodes.
When should data be added to apc?
Data that you would want to cache using apc_fetch(), apd_store() etc. are ideally values that would take some processing time to get generated, rather than simply "all my globals".
Related
Is there a more contemporary alternative to PHP session or is PHP session still the main choice to store information? I read this: https://pasztor.at/blog/stop-using-php-sessions. I'm still learning PHP and frankly, I'm quite clueless.
Your first assumption is incorrect. PHP Sessions are not where you store data. Databases, files, Document stores, etc. are where you store your data.
Session "data" is simply the variables included in the $_SESSION array in serialized form. You can run serialize() and unserialize() on variables to gain some insight into what these look like.
In your script, once you have started a session using session_start(), when you add change or delete variables in $_SESSION, php serializes this and stores it for you.
Once a session exists, and a user makes another request that is identified as being the same user (having the same session id) which has typically passed to the client via a cookie, then upon issuing session_start(), PHP reads the serialized data in the session file, and unserializes it, and stores it back into $_SESSION.
By default, PHP will store the individual session data as files on the filesystem. For a small or medium size application, this is highly performant.
So to be clear, what people store in PHP sessions is basically variables read out of whatever other persistent storage you might have, so that you can avoid doing things like re-querying a database to get the name and user_id for a user who has already logged into your application.
It is not the master version of that data, nor the place through which you will update that data should it change. That will be the original database or mongodb collection.
The article you posted has a number of stated and unstated assumptions including:
Devops/Sysadmins just decide to reconfigure PHP applications to change the session handlers (misleading/false)
The deployment involves a load balancer (possibly)
The load balancer doesn't support or use sticky sessions
He then goes on into some detail as to several alternatives that allow for shared session handlers to solve the race conditions he describes
As you stated, you aren't clear yet what sessions actually are, or how they work or what they do for you. The important thing to know about PHP scripts is that they are tied to a single request and sessions are a way of not repeating expensive database reads. It's essentially variable cache for PHP to use (or not) when it suits your design.
At the point you have a cluster, as pointed out in the article people often store data into shared resources which can be a relational database, or any of many other backends which each have different properties that match their goals.
Again, in order to change the session handlers, there is typically code changes being made to implement the session handler functions required, and there are ways to code things that mitigate the issues brought up in the article you posted, for just about every persistence product that people use.
Last but not least, the problems described exist to whatever degree with pretty much any clustered serverside process and are not unique to PHP or its session mechanism.
Usually, that will depends on the use case and other requirements of your application and most of the time people will use PHP frameworks to handle sessions.
Take for example, for Yii 2 framework, the framework provides different session classes for implementing the different types of session storage. Take a look at here https://www.yiiframework.com/doc/guide/2.0/en/runtime-sessions-cookies.
Learning the different types of sessions available out there, allows you to be able to make decisions by weighing the pros and cons. You can also read here for more understanding https://www.phparch.com/2018/01/php-sessions-in-depth/
I am developing a website and after the login authentication, i am using $_SESSION super global array to pass my data to other pages and display when required. This is how i am doing this. Its my own little MVC framework.
//please ignore the syntax errors
$recieved_data = $this->registry->{auth_login}($username, $password);
//$recieved_data holds records like (fname,lname,email,username,password)
$_SESSION = $recieved_data;
//Or should i choose PHP cache instead at this point?
My website will have a huge traffic after some time. In this particular case, should i choose php cache or keep continue using $_SESSION?
I know i cannot ignore the use of sessions completely but what are the right options in my case?
Today, i surprised when i set the $_SESSION array with different index names in all the projects and used print_r($_SESSION) function to check the available sessions in $_SESSION Array in any one of the project.
It showed me all active sessions belonging to different project folders. Is it fine if the $_SESSION are globally available in all other projects or its my fault somewhere?
I am using Xampp 1.8.3 with PHP version 5.5.3 and Netbeans 7.4 (candidate release) for writing code. I would be thankful for expert guideline.
Basic rule: Don't abuse the session as a cache!
Here's why: The session data is read every time a request is made. All of it. And it is written back every time a request ends.
So if you write some data into it as a cache, that isn't used in every request, you are constantly reading and writing data that is not needed in this request.
Low amount of data will not affect performance significantly, but serializing, unserializing and disk or network I/O of huge amounts of data will affect it. And you miss the opportunity to use that data shared between multiple sessions.
On the other hand, a cache is no session storage, for obvious reasons: It is shared between all sessions and cannot really contain private data.
Regarding optimization for more traffic: You cannot optimize right now. Whatever usage pattern will evolve, you will only then see where performance is really needed. And you probably will want to scale - with the easiest way being to scale with some sort of cloud service instead of hosting it on your own hardware.
I've been caching the output buffer of pages lately, but now I want to cache the values of variables.
I have a PHP file that does a bunch of MySQL queries, then fills variables with various data from those queries.
Some of those variables will never change but some will change quite often. How can I cache certain variables in this manner? I'm using file-based caching, if it helps.
Yup, file based caching is an option.
There are also other options like memcache and APC
You should have a look at these as well. If your application is putting a lot of load on your MySQL server, and if your DB is already optimized, caching is a step you can take.
You can dump any variable (including an array) using serialize, and the inverse is unserialize.
Dumping to a file would be quite a useless cache solution, you can consider using memcache which can store any variable in memory, but requires some work on server side.
I find that a local mysql with MEMORY tables can be useful, too...
I dont know, how you structured your current caching stuff, so this is just a short template on how you can save any kind of variable (as long as its content is serializeable) to a file.
file_put_contents($filename, serialize($variable));
Since you asked about file-based caching, both memcache and APC are no option, although I would certainly recommend both in cases where the stored data is not too large.
For file based caching, I would recommend you to use a caching framework. For example, you could use Zend_Cache from the Zend Framework. It allows you to store your query results in files by using a nice object oriented interface. Plus, you've got a lot of options, such as validation and serialization. There are also other caching frameworks out there.
I'd like to create something like a very basic chat application. I don't want to use a database, since it'd cause a heavy load on an already strained db. I also don't want to use a flat file, because it have a feeling that it'd become a mess or that it'll have lots of read/writes...
So, I'm wondering if there is a way to have a variable that is accessible in any file and at any time.
Well if you don't want a file, you're left with shared memory.
You could try PHP's shared memory functions, or use an extension like memcache or APC.
You can't share variable values among separate requests - think of each request like the entire program is starting and finishing each time, even if there are several requests happening at once.
You could look into storing data in a cache layer (for example, memcached) however it sounds like you need to cache your database if it's under heavy load. I'd recommend caching your database (again memcached or file-based storage; serialize() data first) and then when that problem is solved store the chat data in the database (which is in turn cached). You need to store it persistently somewhere.
There isn't such thing. Try creating a basic file that saves serialized/json'd version of the variable you want, use php's flock to manage access to that file, cycle the file every hour/day. Since it's no big traffic simple app, I think this will be okay.
When I first meet PHP, I'm amazed by the idea Sharing-Nothing-Architecture. I once in a project whose scalaiblity suffers from sharing data among different HTTP requests.
However, as I proceed my PHP learning. I found that PHP has sessions. This looks conflict with the idea of sharing nothing.
So, PHP session is just invented to make counterpart technology of ASP/ASP.NET/J2EE? Should high scalable web sites use PHP session?
The default PHP model locks sessions on a per-user basis. That means that if user A is loading pages 1 and 2, and user B is loading page 3, the only delay that will occur is that page 2 will have to wait until page 1 is done - page 3 will still load independently of pages 1 and 2 because there is nothing shared for separate users; only within a given session.
So it's basically a half-and-half solution that works out okay in the end - most users aren't loading multiple pages simultaneously; thus session lock delays are typically low. As far as requests from different users are concerned, there's still nothing shared.
PHP allows you to write your own session handler - so you can build in your own semantics using the default hooks - or, if you prefer you could use the built in functionality to generate the session id and deal with the browser side of things then write your own code to store/fetch the session data (e.g. if you only wanted the login page and not other pages to lock the session data during processing, then this is a bit tricky though not impossible using the standard hooks).
I don't know enough about the Microsoft architecture for session handling to comment on that, but there's a huge difference in the way that PHPs session handling, and what actually gets stored in the session compared with J2EE.
Not using sessions in most of your pages will make the application tend to perform a lot faster and potentially scale more easily - but you could say that about any data used by the application.
C.